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Abstract 
Domain Name System (DNS) names are "case insensitive". This document 
explains exactly what that means and provides a clear specification 


of the rules. This clarification updates RFCs 1034, 1035, and 2181. 
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Les 


Introduction 


The Domain Name System (DNS) is the global hierarchical replicated 
distributed database system for Internet addressing, mail proxy, and 
other information. Each node in the DNS tree has a name consisting 
of zero or more labels [STD13, RFC1591, RFC2606] that are treated in 
a case insensitive fashion. This document clarifies the meaning of 
"case insensitive" for the DNS. This clarification updates RFCs 
1034, 1035 [STD13], and [RFC2181]. 


The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 


document are to be interpreted as described in [RFC2119]. 


Case Insensitivity of DNS Labels 


DNS was specified in the era of [ASCII]. DNS names were expected to 
look like most host names or Internet email address right halves (the 
part after the at-sign, "@") or to be numeric, as in the in-addr.arpa 


part of the DNS name space. For example, 


foo.example.net. 
aol.com. 
www.gnu.ai.mit.edu. 

or 69.2.0.192.in-addr.arpa. 


Case-varied alternatives to the above [RFC3092] would be DNS names 
like 


Foo.ExamplE.net. 
AOL.COM. 
WWW.gnu.AI.mit.EDU. 

or 69.2.0.192.in-ADDR.ARPA. 


However, the individual octets of which DNS names consist are not 
limited to valid ASCII character codes. They are 8-bit bytes, and 
all values are allowed. Many applications, however, interpret them 
as ASCII characters. 


Escaping Unusual DNS Label Octets 


In Master Files [STD13] and other human-readable and -writable ASCII 
contexts, an escape is needed for the byte value for period (0x2E, 
".") and all octet values outside of the inclusive range from 0x21 
("I") to Ox7E ("7%"). That is to say, Ox2E and all octet values in 
the two inclusive ranges from 0x00 to 0x20 and from Ox7F to OxFF. 
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One typographic convention for octets that do not correspond to an 
ASCII printing graphic is to use a back-slash followed by the value 
of the octet as an unsigned integer represented by exactly three 
decimal digits. 


The same convention can be used for printing ASCII characters so that 
they will be treated as a normal label character. This includes the 
back-slash character used in this convention itself, which can be 
expressed as \092 or \\, and the special label separator period 
("."), which can be expressed as and \046 or \. It is advisable to 
avoid using a backslash to quote an immediately following non- 
printing ASCII character code to avoid implementation difficulties. 


A back-slash followed by only one or two decimal digits is undefined. 
A back-slash followed by four decimal digits produces two octets, the 
first octet having the value of the first three digits considered as 
a decimal number, and the second octet being the character code for 
the fourth decimal digit. 


2.2. Example Labels with Escapes 


The first example below shows embedded spaces and a period (".") 
within a label. The second one shows a 5-octet label where the 
second octet has all bits zero, the third is a backslash, and the 
fourth octet has all bits one. 


Donald\032E\.\032EBastlake\0323rd.example. 
and a\000\\\255z.example. 


3. Name Lookup, Label Types, and CLASS 


According to the original DNS design decision, comparisons on name 
lookup for DNS queries should be case insensitive [STD13]. That is 
to say, a lookup string octet with a value in the inclusive range 
from 0x41 to Ox5A, the uppercase ASCII letters, MUST match the 
identical value and also match the corresponding value in the 
inclusive range from 0x61 to Ox7A, the lowercase ASCII letters. A 
lookup string octet with a lowercase ASCII letter value MUST 
similarly match the identical value and also match the corresponding 
value in the uppercase ASCII letter range. 


(Historical note: The terms "uppercase" and "lowercase" were invented 
after movable type. The terms originally referred to the two font 
trays for storing, in partitioned areas, the different physical type 
elements. Before movable type, the nearest equivalent terms were 
"majuscule" and "minuscule".) 
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One way to implement this rule would be to subtract 0x20 from all 
octets in the inclusive range from 0x61 to Ox7A before comparing 
octets. Such an operation is commonly known as "case folding", but 
implementation via case folding is not required. Note that the DNS 
case insensitivity does NOT correspond to the case folding specified 
in [ISO-8859-1] or [ISO-8859-2]. For example, the octets OxDD (\221) 
and OxFD (\253) do NOT match, although in other contexts, where they 
are interpreted as the upper- and lower-case version of "Y" with an 
acute accent, they might. 


3.1. Original DNS Label Types 


DNS labels in wire-encoded names have a type associated with them. 
The original DNS standard [STD13] had only two types: ASCII labels, 
with a length from zero to 63 octets, and indirect (or compression) 
labels, which consist of an offset pointer to a name location 
elsewhere in the wire encoding on a DNS message. (The ASCII label of 
length zero is reserved for use as the name of the root node of the 
name tree.) ASCII labels follow the ASCII case conventions described 
herein and, as stated above, can actually contain arbitrary byte 
values. Indirect labels are, in effect, replaced by the name to 
which they point, which is then treated with the case insensitivity 
rules in this document. 


3.2. Extended Label Type Case Insensitivity Considerations 


DNS was extended by [RFC2671] so that additional label type numbers 
would be available. (The only such type defined so far is the BINARY 
type [RFC2673], which is now Experimental [RFC3363].) 


The ASCII case insensitivity conventions only apply to ASCII labels; 
that is to say, label type 0x0, whether appearing directly or invoked 
by indirect labels. 


3.3. CLASS Case Insensitivity Considerations 


As described in [STD13] and [RFC2929], DNS has an additional axis for 
data location called CLASS. The only CLASS in global use at this 
time is the "IN" (Internet) CLASS. 


The handling of DNS label case is not CLASS dependent. With the 
original design of DNS, it was intended that a recursive DNS resolver 
be able to handle new CLASSes that were unknown at the time of its 
implementation. This requires uniform handling of label case 
insensitivity. Should it become desirable, for example, to allocate 
a CLASS with "case sensitive ASCII labels", it would be necessary to 
allocate a new label type for these labels. 
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4. 


4. 


4 


Case on Input and Output 


While ASCII label comparisons are case insensitive, [STD13] says case 
MUST be preserved on output and preserved when convenient on input. 
However, this means less than it would appear, since the preservation 
of case on output is NOT required when output is optimized by the use 
of indirect labels, as explained below. 


1. DNS Output Case Preservation 


[STD13] views the DNS namespace as a node tree. ASCII output is as 
if a name were marshalled by taking the label on the node whose name 
is to be output, converting it to a typographically encoded ASCII 
string, walking up the tree outputting each label encountered, and 
preceding all labels but the first with a period ("."). Wire output 
follows the same sequence, but each label is wire encoded, and no 
periods are inserted. No "case conversion" or "case folding" is done 
during such output operations, thus "preserving" case. However, to 
optimize output, indirect labels may be used to point to names 
elsewhere in the DNS answer. In determining whether the name to be 
pointed to (for example, the QNAME) is the "same" as the remainder of 
the name being optimized, the case insensitive comparison specified 
above is done. Thus, such optimization may easily destroy the output 
preservation of case. This type of optimization is commonly called 
"name compression". 


-2. DNS Input Case Preservation 


Originally, DNS data came from an ASCII Master File as defined in 
[STD13] or a zone transfer. DNS Dynamic update and incremental zone 
transfers [RFC1995] have been added as a source of DNS data [RFC2136, 
RFC3007]. When a node in the DNS name tree is created by any of such 
inputs, no case conversion is done. Thus, the case of ASCII labels 
is preserved if they are for nodes being created. However, when a 
name label is input for a node that already exists in DNS data being 
held, the situation is more complex. Implementations are free to 
retain the case first loaded for such a label, to allow new input to 
override the old case, or even to maintain separate copies preserving 
the input case. 


For example, if data with owner name "foo.bar.example" [RFC3092] is 
loaded and then later data with owner name "xyz.BAR.example" is 
input, the name of the label on the "bar.example" node (i.e., "bar") 
might or might not be changed to "BAR" in the DNS stored data. Thus, 
later retrieval of data stored under "xyz.bar.example" in this case 
can use "xyz.BAR.example" in all returned data, use "xyz.bar.example" 
in all returned data, or even, when more than one RR is being 
returned, use a mixture of these two capitalizations. This last case 
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is unlikely, as optimization of answer length through indirect labels 
tends to cause only one copy of the name tail ("bar.example" or 
"BAR.example") to be used for all returned RRs. Note that none of 
this has any effect on the number or completeness of the RR set 
returned, only on the case of the names in the RR set returned. 


The same considerations apply when inputting multiple data records 
with owner names differing only in case. For example, if an "A" 
record is the first resource record stored under owner name 
"xyz.BAR.example" and then a second "A" record is stored under 
"XYZ.BAR.example", the second MAY be stored with the first (lower 
case initial label) name, the second MAY override the first so that 
only an uppercase initial label is retained, or both capitalizations 
MAY be kept in the DNS stored data. In any case, a retrieval with 
either capitalization will retrieve all RRs with either 
capitalization. 


Note that the order of insertion into a server database of the DNS 
name tree nodes that appear in a Master File is not defined so that 
the results of inconsistent capitalization in a Master File are 
unpredictable output capitalization. 


5. Internationalized Domain Names 


A scheme has been adopted for "internationalized domain names" and 
"internationalized labels" as described in [RFC3490, RFC3454, 
RFC3491, and RFC3492]. It makes most of [UNICODE] available through 
a separate application level transformation from internationalized 
domain name to DNS domain name and from DNS domain name to 
internationalized domain name. Any case insensitivity that 
internationalized domain names and labels have varies depending on 
the script and is handled entirely as part of the transformation 
described in [RFC3454] and [RFC3491], which should be seen for 


further details. This is not a part of the DNS as standardized in 
STD 13. 
6. Security Considerations 


The equivalence of certain DNS label types with case differences, as 
clarified in this document, can lead to security problems. For 
example, a user could be confused by believing that two domain names 
differing only in case were actually different names. 


Furthermore, a domain name may be used in contexts other than the 
DNS. It could be used as a case sensitive index into some database 
or file system. Or it could be interpreted as binary data by some 
integrity or authentication code system. These problems can usually 
be handled by using a standardized or "canonical" form of the DNS 
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ASCII type labels; that is, always mapping the ASCII letter value 
octets in ASCII labels to some specific pre-chosen case, either 


uppercase or lower case. An example of a canonical form for domain 
names (and also a canonical ordering for them) appears in Section 6 
of [RFC4034]. See also [RFC3597]. 


Finally, a non-DNS name may be stored into DNS with the false 
expectation that case will always be preserved. For example, 
although this would be quite rare, on a system with case sensitive 
email address local parts, an attempt to store two Responsible Person 
(RP) [RFC1183] records that differed only in case would probably 
produce unexpected results that might have security implications. 
That is because the entire email address, including the possibly case 
sensitive local or left-hand part, is encoded into a DNS name ina 
readable fashion where the case of some letters might be changed on 
output as described above. 
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